Just a heads up that the blog PR totally overhauls how the dry-run clients above log, so keep an eye on that depending on whether this lands before or after the blog PR.

If you wanted to be really fancy, you could use a FieldMask to control which fields get updated, rather than relying on zero-values.

But as cool as FieldMasks are, we don't use them anywhere else, and this probably isn't the time to start. If we want to use them, we should make a concerted effort to use them everywhere. Anyway, just sharing for fun.

Idea: if s.serialsFile is -, then open stdin. Alternatively, add documentation noting that a user could pass /dev/stdin as the file to read from if they want to stream serials on stdin.

We've got two plurality mismatches here:

• The message and RPC names both imply a singular incident table, but every message in the stream carries its own serialTable value, which could theoretically change from one message to the next.
• The repeated field within the message has a singular name, which is non-idiomatic (we pluralize names of repeated fields).

I think there are several options of varying complexity for what to do:

1. Change the field name to serials and call it a day.
2. Make the serial field non-repeated, and don't batch lots of serials into a single message.
3. Split this stream into two different kinds of messages, a "metadata" message and a "serials" message, just like ca.GenerateCRL does.

I don't have strong opinions on which approach you take here. 1 is the smallest diff but only addresses one of the two issues; 2 results in the simplest code by ditching batching but has reduced efficiency and only addresses one of the two issues; 3 is the most comprehensive but is admittedly complex.

Should this not return Incident, reflecting the new state of the world, just like Create?

super-nit: CREATE is the somewhat surprising/unusual permission here, so I'd list it first. (And same in the other file.)

Hmm, I'm not sure this quite makes sense. On line 69, it makes sense to initialize dbReadOnlyMap to dbMap, because the latter can be assumed to have a superset of the permissions that the former needs, so falling back will still allow everything to work. Here, it shouldn't be assumed that dbIncidentsMap can do everything that dbIncidentsWriteMap needs to do.

Minor comment: calling this buf feels weird, because I expect that to be a byte buffer, not a list of strings. Maybe pool or batch or something like that.

Larger comment: how much performance win are we getting from batching both here and at the SA level? Batching here (and unbatching at the SA, before immediately rebatching with a batch size that happens to be the same but can't be assumed to be the same) adds a lot of complexity. We haven't decided that we need that level of complexity for producing CRLs, which have to handle roughly the same number of serials as this, since any serials we load here will end up on CRLs a few minutes later. If a load test has shown that gRPC between the admin tool and the SA is a bottleneck we need to overcome, then great, this is worth it. But if doing 10k-row inserts into the database is still going to be the primary bottleneck, I'd have a preference for keeping this simple.

Might be worth adding an explicit check that the table exists, so we can provide a better error message if it doesn't? Totally optional, feel free to ignore.